When an epoch change starts while node recovery is in progress, the
recovery task was canceled and restarted from scratch, re-scanning the
full blob info table on every epoch change even though the previous
progress was still valid.

The recovery task now keeps running across epoch changes:

- The epoch-change path only advances the recovery target
  (RecoveryInProgress epoch) and starts shard syncs for gained shards;
  both happen under a new status mutex so that they are atomic with
  respect to the recovery task's completion. A new task is only started
  if the running task completed concurrently with the epoch change or
  stopped unexpectedly; a spurious start is harmless since the extra
  task exits once it observes that the node is already active.
- The task's scan bound stays frozen at the epoch it was started with:
  blobs certified later are covered by event processing, and shards
  gained at later epoch changes are covered by shard sync, which the
  task waits for.
- On completion, the task attests epoch sync done for the recovery
  target currently recorded in the node status (which epoch changes
  advance), instead of the frozen spawn epoch whose attestation would
  be dropped as stale.
- Attestation requires a clean scan pass during which no shard sync
  started, tracked by a new shard sync generation counter: a shard sync
  that starts and terminally fails during a pass leaves missing blobs
  behind that only a new scan pass finds. The blob scan also pauses
  promptly when a shard sync starts mid-pass, since per-blob recovery
  would redundantly decode slivers for shards that shard sync copies
  in bulk.

The shard-gain simtest now also asserts that epoch changes processed
while recovering do not restart the recovery task.

…ch sync done

Hold the recovery status mutex through the shards_to_lock loop in
process_shard_changes_in_new_epoch_while_recovering. Previously the guard
was dropped after starting shard syncs but before locking lost shards, so
on an epoch change with lost shards only, the running recovery task could
complete and attest epoch sync done while the node still accepted slivers
for shards it no longer owns. This matches the catch-up path, which
already locks shards under the guard.